Re: Re: [GENERAL] +/- Inf for float8's - Mailing list pgsql-hackers

From Henry B. Hotz
Subject Re: Re: [GENERAL] +/- Inf for float8's
Date
Msg-id v04210176b5c73dae36fa@[137.78.84.130]
Whole thread Raw
In response to Re: Re: [GENERAL] +/- Inf for float8's  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
At 1:25 AM -0400 8/21/00, Tom Lane wrote:
>"Ross J. Reedstrom" <reedstrm@rice.edu> writes:
> > !     if (isnan(a))
> > !         PG_RETURN_INT32(1);
>
>Do not like this at all --- doesn't it make the result of btint4cmp(NaN,
>NaN) dependent on which argument chances to be first?  Seems to me that
>you must consider two NaNs to be equal, unless you want to subdivide
>the category of NaNs.

I'm pretty sure IEEE 754 says that NaN does not compare equal to 
anything, including themselves.  I also believe that Infinity isn't 
equal to itself either, it's just bigger than anything else except 
NaN (which isn't littler either).

Without having seen the start of this thread I think the biggest 
problem is that some of the results of compares depend on the mode 
that the FP hardware is put in.  IEEE specifies some modes, but not 
how you set the mode you want on the system you are actually running 
on.  For example I think comparing zero and -Infinity may return 
three possible results:  0 > -Infinity, 0 < -Infinity (because it was 
told to ignore the sign of Infinity), or an illegal value exception. 
Likewise signalling/non-signalling NaN's act different depending on 
mode settings.

We need to first figure out what floating point behavior we want to 
support.  Then we figure what mode settings provide that behavior 
with a minimum of overhead.  Then we need to figure out how to set 
those modes on all the platforms we support.  We will probably 
discover that not all required modes actually exist on all hardware 
platforms.  I know that 68000 and SPARC are pretty good, but PowerPC 
punted some stuff to exception handlers which may not be correct on 
all OS's.  I've heard that Java has some portability issues because 
Intel fudged some stuff in the newer hardware.

Does anyone feel like tracing down how to set the modes for all the 
different systems that we try to run on?  If there is interest then I 
might poke at a couple/three NetBSD ports and Solaris/SPARC.  But 
only if there is interest.

Sun has put some code out under GPL which will let you test for these 
special values and handle them, but that seems like a big hit for 
what should be a simple compare.  I assume that we can't put GPL code 
into the main sources any more than the *BSD's do.  Perhaps we could 
get away with it if it is only included if configure can't figure out 
how to set the modes properly?


Signature held pending an ISO 9000 compliant
signature design and approval process.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu


pgsql-hackers by date:

Previous
From: Ned Lilly
Date:
Subject: Re: Bug tracking
Next
From: Hannu Krosing
Date:
Subject: Re: Optimisation deficiency: currval('seq')-->seq scan, constant-->index scan